Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/main/java/cc/backend/kakaoPay/controller/KakaoPayController.java`:
- Around line 50-62: The cancel and fail GET handlers (methods cancel and fail)
call kakaoPayBusinessService.stopPayment using an unauthenticated
partner_order_id, allowing attackers to expire tickets by guessing IDs; modify
preparePayment to emit a short-lived signed token/HMAC tied to partner_order_id
(and optionally timestamp/nonce) and include it in the redirect URL, then
validate that token in the cancel and fail endpoints before calling stopPayment
(reject or ignore requests with missing/invalid/expired tokens); ensure
validation uses a server-side secret and check signature + expiry to prevent
replay.
- Around line 52-62: Add structured logging to KakaoPayController by annotating
the class with a logging annotation (e.g., `@Slf4j`) and replace any
e.printStackTrace() calls in the cancel method (and the similar block at lines
67-77) with log.error statements that include a clear message and the exception
(e.g., log.error("Failed to cancel payment for partnerOrderId={}, redirecting to
front", partnerOrderId, e)); ensure you import/use the same logger across the
class so exceptions are captured by the app's logging framework.
- Around line 23-25: Replace the hardcoded FRONT_DOMAIN constant with an
externalized property: remove the private static final String FRONT_DOMAIN =
"https://seeatheater.site" and restore an `@Value-injected` field in
KakaoPayController (e.g., add `@Value`("${front.domain}") private String
FRONT_DOMAIN) so the controller reads the URL from configuration/environment;
add the property mapping in application.yml (front.domain: ${FRONT_DOMAIN}) or
ensure FRONT_DOMAIN is provided as an env var, and update any references to use
the injected FRONT_DOMAIN field.

In `@src/main/java/cc/backend/kakaoPay/service/KakaoPayBusinessService.java`:
- Around line 190-192: The code currently calls Long.valueOf(partnerOrderId) in
stopPayment which will throw NumberFormatException for non-numeric input; wrap
the parse in a try-catch, catch NumberFormatException, log a clear message
including the offending partnerOrderId and the exception, and then return a safe
failure (e.g., throw an IllegalArgumentException or a domain-specific exception)
instead of allowing the unchecked exception to propagate silently; update
callers if needed so the scheduler and controller handle the returned/raised
error consistently.

In `@src/main/java/cc/backend/scheduler/TempTicketExpireScheduler.java`:
- Around line 27-28: The scheduler in TempTicketExpireScheduler uses
LocalDateTime.now(ZoneId.of("Asia/Seoul")) to compute expireTime while persisted
createdAt in BaseEntity is timezone-unaware (JVM default/UTC), causing a 9-hour
mismatch; change the scheduler to use the same timezone as persistence (replace
LocalDateTime.now(ZoneId.of("Asia/Seoul")) and expireTime calculation with
LocalDateTime.now() if your JVM/database uses UTC) or alternatively configure
hibernate.jdbc.time_zone to a fixed zone and make both BaseEntity persistence
and TempTicketExpireScheduler use that same zone consistently; update any
related tests/comments to reflect the chosen approach.

In `@src/main/java/cc/backend/ticket/repository/TempTicketRepository.java`:
- Around line 39-45: The JPQL in TempTicketRepository.findExpiredPendingTickets
uses the string literal 'PENDING' which is brittle; update the query to
reference the enum constant directly (e.g., use the fully qualified enum
reference like YourReservationStatusEnumType.PENDING in the WHERE clause) so the
JPQL compares against the enum constant rather than a string, or if you prefer a
reusable API, change the method signature to accept a ReservationStatus
parameter (ReservationStatus status, LocalDateTime expireTime) and use that
parameter in the WHERE clause and pass ReservationStatus.PENDING from the
scheduler; adjust imports and tests accordingly.

---

Outside diff comments:
In `@src/main/java/cc/backend/kakaoPay/controller/KakaoPayController.java`:
- Around line 36-47: The approve method lacks error handling: wrap the call to
kakaoPayBusinessService.completePayment(partnerOrderId, pgToken) inside a
try-catch in the approve(...) controller, and on success keep the existing
response.sendRedirect(FRONT_DOMAIN + "/ticketing/" + result.getAmateurShowId() +
"?payment=success"); but on any exception catch it and redirect the user to the
same ticketing page (or a safe fallback) with an error query like
"?payment=fail" (or "?payment=error") to mirror cancel/fail behavior; ensure you
catch Exception, log the error, and still call response.sendRedirect with the
error indicator so users never see a raw 500.

---

Nitpick comments:
In `@src/main/java/cc/backend/kakaoPay/service/KakaoPayBusinessService.java`:
- Around line 190-214: The stopPayment method currently uses
tempTicketRepository.findById which triggers lazy-loading when accessing
tempTicket.getAmateurRound().getAmateurShow().getId(); replace the findById call
with tempTicketRepository.findWithTicketAndShowById(partnerOrderIdLong) (or the
equivalent signature) so the amateurRound and amateurShow are eagerly fetched
via the repository's `@EntityGraph`, preserving the existing orElseThrow(()-> new
GeneralException(ErrorStatus.TEMP_TICKET_NOT_FOUND)) behavior; keep the rest of
the logic (checking ReservationStatus,
amateurRoundsRepository.increaseStock(...), and
tempTicket.updateReservationStatus(...)) unchanged.